home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
gt_power
/
bgqwkb40.zip
/
BGQWK.DOC
next >
Wrap
Text File
|
1992-11-08
|
63KB
|
1,169 lines
VOICE B.J. GUILLOT MODEM
(713) 893-9320 2611 RUSHWOOD CIRCLE (713) 893-9124
HOUSTON TEXAS 77067-1941 v32bis 14.4K
Copyright B.J. Guillot 1991-1992. All Rights Reserved.
=============================================================
BGQWK 1.0 beta 39 revised 08 NOV 92
BGQWK 1.0 beta 37 revised 18 OCT 92
BGQWK 1.0 beta 36 revised 20 SEP 92
BGQWK 1.0 beta 35 revised 27 AUG 92
BGQWK 1.0 beta 34 revised 04 AUG 92
BGQWK 1.0 beta 19 original 29 DEC 91
=============================================================
Dedicated to Gene Roddenberry
1921-1991
╔═════════════════════════════════════════════════════════════════╗
║ E02/758 sponsored by 001/070 is the OFFICIAL SUPPORT CONFERENCE ║
╚═════════════════════════════════════════════════════════════════╝
-------------------------------------------------------------
ABSTRACT
-------------------------------------------------------------
BGQWK has two modes of operation. When used as a door, users can
prepare universal QWK mail packets online and upload REP reply
packets. When used in prepack mode, BGQWK creates a specific
user's QWK packet offline for later downloading through GT Power.
BGQWK can presently be used with GT 15.00, 15.50, 16.00, 17.00
and 17.06 with any number of active nodes.
-------------------------------------------------------------
INCLUDED FILES
-------------------------------------------------------------
1. BGQWK.DOC -- documentation
2. BGQWK.HLP -- help file shown to users when in bgqwk door
3. BGQWK.EXE -- the main executable
4. REGISTER.FRM -- registration form
-------------------------------------------------------------
EXTERNAL PROGRAMS
-------------------------------------------------------------
Be sure you have the following files handy ...
1. COMMAND.COM in your COMSPEC
2. DSZ.COM (or DSZ.EXE) in your PATH
3. PKZIP.EXE in your PATH
4. PKUNZIP.EXE in your PATH
5. HSLINK.EXE in your PATH (optional)
6. ARJ.EXE in your PATH (optional)
7. LHA.EXE (or LHARC.EXE) in your PATH (optional)
-------------------------------------------------------------
CONFIGURATION
-------------------------------------------------------------
BGQWK requires a configuration file in order to run. This file
may be placed in the GTPATH or LANPATH directories. In order to
explain the configuration with ease, take a look at this example:
id=TRANQUIL
sn=B.J. Guillot
bn=Tranquility Base
bc=Houston, Texas
bp=713-893-9124
up=C:\GT\UPLOADS
we=C:\GT\BBSFILE\GTWELCOM.CBS
ne=C:\GT\BBSFILE\GTBULLET.CBS
by=C:\GT\BBSFILE\GTBYE.CBS
ma=100
mp=1000
ns=John Doe/gt
ns=Node Houston/tx
ns=Jimmy Dean/rn gt
nt=1
dn=gt
----+---+------------+[xx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
000 | z | Main Board | lo=D:\MAIL\GENERAL
045 | z | General | tx=D:\MAIL\TNET001,P
046 | z | Aggies | tx=D:\MAIL\TNET003,P
047 | z | Buy/Sell | tx=D:\MAIL\TNET004,P
048 | z | Politics | tx=D:\MAIL\TNET005,P
049 | z | Singles | tx=D:\MAIL\TNET006,PA
050 | 0 | Admin | tx=D:\MAIL\TNET002,P
005 | z | Common | rn=D:\MAIL\RNET004
; this is a comment line ... notice it begins with a semicolon
038 | z | Faxmail | rn=D:\MAIL\RNET278
051 | z | Global | rn=D:\MAIL\RNET082
037 | z | Rime News | rn=D:\MAIL\RNET200,R
023 | z | Rime Users | rn=D:\MAIL\RNET104
052 | z | Uplink | rn=D:\MAIL\RNET024
001 | z | Ansi Art | rn=D:\MAIL\RNET109
002 | z | Assembler | rn=D:\MAIL\RNET135
003 | z | Astronomy | rn=D:\MAIL\RNET088
004 | z | C | rn=D:\MAIL\RNET100
006 | z | Comp Tech | rn=D:\MAIL\RNET006
012 | z | Cult TV | rn=D:\MAIL\RNET245
007 | z | Debate | rn=D:\MAIL\RNET003
008 | z | Doctor Who | rn=D:\MAIL\RNET116
009 | z | Engineer | rn=D:\MAIL\RNET108
010 | z | Entertain | rn=D:\MAIL\RNET016
011 | z | For Sale | rn=D:\MAIL\RNET002
013 | z | Fractals | rn=D:\MAIL\RNET148
016 | z | Hard Disk | rn=D:\MAIL\RNET014
017 | z | Ham Radio | rn=D:\MAIL\RNET015
018 | z | LAN | rn=D:\MAIL\RNET017
019 | z | Offline | rn=D:\MAIL\RNET264
020 | z | Pascal | rn=D:\MAIL\RNET097
021 | z | Program'ng | rn=D:\MAIL\RNET010
022 | z | QuickBasic | rn=D:\MAIL\RNET099
024 | z | Religion | rn=D:\MAIL\RNET076
025 | z | Sci/Tech | rn=D:\MAIL\RNET083
026 | z | Sci/Fi | rn=D:\MAIL\RNET030
027 | z | Shareware | rn=D:\MAIL\RNET056
035 | z | SLMR | rn=D:\MAIL\RNET260
028 | z | Star Trek | rn=D:\MAIL\RNET101
029 | z | Strange | rn=D:\MAIL\RNET179
030 | z | Tandy | rn=D:\MAIL\RNET129
031 | z | USR/HST | rn=D:\MAIL\RNET023
032 | z | Video Tech | rn=D:\MAIL\RNET192
033 | z | Windows | rn=D:\MAIL\RNET044
034 | z | Wire Wrap | rn=D:\MAIL\RNET199
014 | 0 | Admin | rn=D:\MAIL\RNET025
036 | 0 | Sysops | rn=D:\MAIL\RNET001
015 | z | Gfx Proj | rn=D:\MAIL\RNET261
040 | 0 | Netmail | gt=D:\MAIL\NETMAIL,N
041 | z | AnsiArt | gt=D:\MAIL\E10-037,P
039 | z | Bg Qwk | gt=D:\MAIL\E02-758,P
042 | z | GT Power | gt=D:\MAIL\E00-001,P
043 | 0 | GT Beta | gt=d:\MAIL\E01-009,P
044 | 0 | Hou Chat | gt=D:\MAIL\E20-002,P
Let's go over the above file one step at a time.
ID= This is what will be used as your board "id". It can be
up to eight characters long. If omitted, the default "id"
will be "NONAME".
SN= This is what will be used as the sysop's name. This too is
optional, and if not used, will default to "Sysop", which
doesn't do much for you. When users enter messages to
"Sysop" through their QWK reader, if this is used, the name
will be translated to the name specified here.
BN= This is where the name of your board goes. If omitted, the
default is "NONAME".
BC= This is where the city and state of your board goes. If
omitted, the default is "Planet, Earth".
BP= This is where the phone number of your board goes. If
omitted, the default is "000-000-0000".
UP= BGQWK will create, on request by the user, a list of new
files available on the board since their last file scan.
If you wish to specify a different directory to scan for
files, this is where do you do it. If this is omitted, the
directory to be checked for files will be taken out of the
GT.CNF file (from directive UP=).
WE= BGQWK will create, on request by the user, a WELCOME file to
be displayed when reading their packet (depending upon the
software they are using). If this is omitted, BGQWK will use
the GTWELCOM.CBS file found in your GTPATH or BBS/CBS
directory as the WELCOME file. If another file is specified,
it will be used as the WELCOME file.
NE= BGQWK will create, on request by the user, a NEWS file to be
displayed when reading their packet (depending upon the
software they are using). If this is omitted, BGQWK will use
the GTBULLET.CBS file found in your GTPATH or BBS/CBS
directory as the NEWS file. If another file is specified, it
will be used as the NEWS file.
BY= BGQWK will create, on request by the user, a GOODBYE file to
be displayed when reading their packet (depending upon the
software they are using). If this is omitted, BGQWK will use
the GTBYE.CBS file found in your GTPATH or BBS/CBS directory
as the GOODBYE file. If another file is specified, it will
be used as the GOODBYE file.
MA= As the sysop, you can specify the maximum messages per
conference a user can download. The user can also select how
many maximum messages per conference in the door, but will
never be able to override the limit specified here. If this
is omitted, the maximum will be set to 100. Please note,
that this "limit" is FLEXIBLE, meaning that it applies only
at a base of 2400 bps. If you user is connected at 9600, the
maximum default will be 400 messages per conference. If they
are at 1200 bps, the maximum default will be 50 messages.
MP= As the sysop, you can specify the maximum messages per packet
a user can download. The user can also select how many
maximum messages per packet in the door, but will never be
able to override the limit specified here. If omitted, the
maximum will be set to 2000. Please note that this "limit"
is FLEXIBLE depending on the users bps rate. The "base" for
this "limit" is set at 2400 bps.
NS= Please see the NET STATUS section in this documentation.
SP= Please see the SPECIAL PEOPLE section in this documentation.
NT= Set this value to your net number if you are joined in a GT
Network. This will determine whether BGQWK is to charge the
user a netmail credit or not when sending netmail.
DN= Set this equal to the "net id" that contains the netmail
confernece you want unaffiliated netmail messages to go into
when posted by users. See the 'N,~' CONFERENCE OPTION
sections a little further down in the documentation for more
information on this.
----+---+------------+[xx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
The line that seperates the configuration information from the
conference information is the above. This is completely optional
and may be removed. Its only purpose to to provide a ruler for
the conference information.
┌─────────────── conference name
│ ┌─── net id ┌─── conference path
000 | z | Main Board | lo=D:\MAIL\GENERAL
045 | z | General | tx=D:\MAIL\TNET001,P
046 | z | Aggies | tx=D:\MAIL\TNET003,R
047 | z | Buy/Sell | tx=D:\MAIL\TNET004,P
048 | z | Politics | tx=D:\MAIL\TNET005,P
049 | z | Singles | tx=D:\MAIL\TNET006,PA
050 | 0 | Admin | tx=D:\MAIL\TNET002,P
005 | z | Common | rn=D:\MAIL\RNET004 │
038 | z | Faxmail | rn=D:\MAIL\RNET278 └─── conference options
│ └─── access level
└──────── conference number
The remaining part of the BGQWK.CNF file consists of the
conference information. Every confernece on your board that you
wish users to have QWK access to _must be_ configure.
Please note that you do not have to configure every conference on
your board. Just the ones you wish users to have access to in the
door--with one exception--you _must_ have the main message base
conference configured (the conference number will not be of
consequence). Remember, the main conference is the one that GT
pops up by default when users login (the conference specified by
the MP= directive in GT.CNF).
CONFERENCE NUMBER
-----------------
The conference number is a very important part of this file.
Please note that the numbers do not have to go in order, but if
you choose to do it that way, be sure to check for duplicate
numbers. If BGQWK finds a conference with a duplicate number, it
will abort with an error message and return to the board.
A maximum of 510 conferences can be used by BGQWK (conferences
numbers 0 to 509). Do not assign any conferences with numbers
higher than 509.
Once you have choosen a conference number for a particular
conference, I _highly_ recommend you keep it that way. Do _not_
shift the conference numbers around. The conference numbers must
be static, they must stay in place. When users upload replies
through BGQWK, the MSG file header instead of the REP packet
stores the conference number that was used when they originally
replied to the message. If a user wrote that reply a week ago and
is just now uploading the packet, if you changed the message base
numbers, their messages will be sent into the wrong conference.
You wouldn't want, say, someone's replies from a sexual oriented
conference to be posted into a religion conference, would you?
In fact, because of conference number, that is another reason why
information cannot be read out of the GTMDIR.BBS file. GT's
message base numbers are dynamic. They change depending on access
level or whenever you insert a message base between another one.
That is unacceptable in the QWK format.
Let's have a little discussion concerning the dos and don'ts of
conference numbers in this file. Say you have conferences 0 to
46. You wish to delete conference 12 because you don't carry it
anymore. No problem. Just load up your editor and zap that
line. CONFERENCE NUMBERS DO NOT HAVE TO BE SEQUENTIAL. THERE CAN
BE BIG GAPS BETWEEN NUMBERS. The QWK readers don't care about
that. But say you are adding a conference that same day. Since
you have a space open at 12, you think about using 12 as the
conference number. Wrong! Make it conference 47. Why? Well,
again, what if a user was using that conference and is going to
upload some replies tomorrow, they will be posted into the wrong
conference. And, as I said before, I don't think you want to mess
with the hassle of that. If you make the new conference 47 and
leave 12 blank for now, that would be fine.
Now, say you pick up another conference a few weeks down the road.
You don't know whether to assign it number 12 or 48. Since so
much time has passed, I doubt users will have any replies waiting
to go into the conference, so I would just toss a coin. It
doesn't really matter after that. It's your decision then.
Conference numbers must be padded, to the left, with zeros. They
are only padded in the configuration file--no where else. This is
done so that the sysop remembers that BGQWK.CNF has a definite
format and can not be changed. Do not take out the pipe bars, |,
between lines. If you do, BGQWK will inform you that the format
has been tampered with and will abort back to the board.
CONFERENCE NAME
---------------
Please note that the conference name is limited to ten characters.
That's all that the QWK format is able to support. You might be
asking "Why don't you pull the information out of GTMDIR.BBS?"
right about this time. There are several reasons for not doing
this. The conference name limit of ten characters is one. If I
pulled the information from the GTMDIR.BBS file, I would have to
truncate the description to only ten characters long. I would
much rather give the sysop the option of naming the conference
because he or she can get the meaning across much more by
abbreviating than by truncation.
ACCESS LEVEL
------------
This part is pretty much self-explantory. The access levels work
the same way they do in GT. BGQWK pulls the users access level
from the USER.CTL file rather than the GTUSER.BBS file. If the
user does not possess the minimum access level required to access
a specific conference, that conference selection will not be shown
to the user.
NET ID
------
This will be discussed further in the NET STATUS section of this
documentation, but it is also a useful tool for the users in
BGQWK. The two letter net id plus the equal sign is optional and
may be left out of the BGQWK.CNF file for specific conferences.
If that is done, BGQWK assumes the conference has a net id of
"LO", local conference.
The net id's must be two letters and only two letters.
On my board, I have the following net id's set up: LO for Local,
RN for RelayNet, GT for GT Network, and TX for TexasNet. When the
users select their conferences through BGQWK, they have the option
of listing all conferences or listing only the conferences from a
particular network. Say they are interested just in TexasNet, for
instance. They can list only the six or seven TexasNet
conferences and not be bothered with all the others. The net id's
work similiar to the message base "boards" in GT 17.00 and later.
CONFERENCE PATH
---------------
The path is represented in the same manner that it is represented
in the GTMDIR.BBS file. You do not need to input a trailing
backslash or the \GTMSGS directory. BGQWK handles that
automatically.
CONFERENCE OPTIONS
------------------
You specify conference options right after the conference path
followed by a comma. These are completly optional and can be
omitted. Here is a list of currently supported options:
G,* Conference is a guest or application only conference. If
specified, when a user tries to join this conference, they
will not be able to download and mail until the sysop
offically "joins" them into the base. BGQWK displays a
"pending" indicator to the user.
A,= Conference is access level exclusive. Even if a user has an
access level high enough to view the conference, if they
don't have the _same_ access level specified as the
conference access level, they will _not_ be given access to
that conference.
N,~ Conference is a GT netmail conference. To send netmail
messages, it requires netmail credits. Because QWK readers
do not know about GT and the way it's netmail system
operates, the user, if he or she wishes to send a true
netmail message, must enter the node/net id as the first line
of the message. Both the net and the node must be padded to
the left with zeros. Example message text:
001/070
Hello, Russell. Just testing netmail!
.DX
Regards,
B.J. Guillot
BGQWK will intercept the "001/070" and change the message
header to reflect a netmail message to that destination.
Please note that netmail messages can be placed in _any_
conference. BGQWK will assume a message is a netmail message
if it contains an "xxx/yyy" netmail address as the first line
in the message. The net and node numbers must be padded with
zeros. Since you can have multiple netmail conferences (for
example, one for GTPN and one for AFSN), BGQWK will select
the netmail conference that has the same "net id" as the
conference the message was entered in; i.e., if you enter a
netmail message in GT/Cookbook it will go into GT/Netmail.
If you enter a message into AF/TradePost, it will go into the
AF/Netmail area. A problem comes up if a user attempts to
enter a netmail message in an UNAFFILIATED conference like
LO/Main Board. BGQWK will essential put the message in the
trash can, because it doesn't know which netmail conference
to place it into. To solve this problem, the "DN=" option in
the BGQWK.CNF file will let BGQWK know which network to route
unaffiliated netmail into. If you set "DN=GT", any LO/Main
Board netmail will be sent in GT/Netmail. If you set "DN=AF",
any LO/Main Board netmail will be sent in AF/Netmail. To
check your netmail "routings", do a S)elect A)ll D)etails
from the BGQWK user prompt to be sure nothing is routed into
the dreaded "TRASH CAN". Please note that you should use the
'V' command line option to disable the searching of the
NODELIST.BBS file if you are joined in multiple networks.
If a user tries to use a "dot" command in netmail, the "dot"
will be turned into an asterick _unless_ that user is granted
sysop authorities. In my sample message above, if I did not
have sysop authorities (SY access in the GTUSER.BBS file),
the .DX would change to *DX so the GT netmail software would
not process it.
P,^ Conference is a public message area _only_. Private messages
are not permitted. You will most likely want this flag on
any GT Network conferences. Because RelayNet can handle
private messages, there is no need to use it on RIME
conferences.
R,< Conference is a read _only_ conference. No messages may be
entered, period.
X,$ Conference is private _only_. No public messages are
permitted.
S Conference is 7 bit only. Any 8 bit characters will be
stripped of their high bit. This option is useful for FidoNet
conferences or UseNet conferences where 8 bit characters are
big bad and naughty. Otherwise, I would not recommend using
this option.
On all standard 8-bit (non-FidoNet) conferences, any psuedo
ANSI code (`[) will be translated to standard ANSI code
(<ESC>[) for viewing within GT when users upload messages.
On 7-bit (FidoNet) conferences, if a user attempts to upload
standard ANSI codes, the code will be converted to psuedo
ANSI as per FidoNet rules.
Please note that many of the above options have two different
characters that do the job. For example, P and ^ both mean public
message area only. I did this for the people who know and love
GT's traditional message flag set. Since I always get confused
with the characters, I just included the letter options for other
people like me.
Also, you can use more than one option per conference. However,
be sure to to use any that "cancel the other out". For example,
you might not want a conference to be public only and private only.
BGQWK might through a fit!
-------------------------------------------------------------
After you have spent forever and a day typing your configuration
file <grin>, you're almost ready to begin! However, listen to
this recommendation closely ... You may want to only enter
conference data for ten conferences, make sure BGQWK runs, and
then type the rest. You don't want to be stuck entering the wrong
format for three hundred echos, do you?
-------------------------------------------------------------
-------------------------------------------------------------
COMMAND LINE OPTIONS AND PARAMETERS
-------------------------------------------------------------
BGQWK requires at least two parameters in order to run. The two
parameters are the command line options and the drive which BGQWK
is expected to work on. Example:
bgqwk mgk f:
The first paramter batch contain specfic options for the way in
which BGQWK operates. The "f:" means work on drive F: will be
used for the work directory.
THE WORK DRIVE
--------------
You might be wondering why the door requires a work drive to be
specified in order to run? Well, when preparing QWK packets, an
enormous amount of space is sometimes required. BGQWK may need
several megabytes to work with depending on how many messages you
allow the user to download and how many messages the user chooses
to download. Don't worry about running out of space, though.
BGQWK will try its best not to eat all the space at once.
You may want to place two doors for BGQWK on your system. This is
the way mine is set up. I have one door for BGQWK on a RAM disk
and one door for BGQWK on a HD. My RAMdisk only supports one
megabyte, but many users don't download packets much larger than
100K most of the time, so they want to access the speed that a
RAMdisk possess when BGQWK is working. The second door just uses
BGQWK on whichever Hard Drive I tell it to use (usually either the
faster one or the one that has the most space).
Oh, and speaking of RAM disks ... I _highly_, _highly_, _highly_
recommend using both a large RAM disk, if you have it, and a large
disk cache. Together, they can make BGQWK fly at supersonic
speeds (well, _much_ faster than it would if you don't run a cache
or RAM disk, anyway).
Of course, using RAM disks and disk caches are totally up to you.
If you're not running them now, it's probably because you don't
have any extra memory lying around. If you do, by all means, find
a disk cache and install it. You will be amazed at how much
faster BGQWK, GT, and all your other programs run.
Anyway, ... when BGQWK runs, it will create it's own work
directory on whatever drive you specify. The directory will be
called \BGQWKpid.WRK, where "pid" is the current PID number of
whatever node is currently using BGQWK. This allows multiple
nodes to use BGQWK at the same time on the same drive. If you are
not using a LAN, the PID number will most likely by "0".
The work directory will always be deleted when the door is exited.
DOOR OPTIONS
------------
5 If specified, BGQWK will run in GT 15 mode and use
individual xxxxx.MSG files rather than the newer ten message
xxxxx.MES files. BGQWK runs much slower in 15 mode
because it has to open and close ten times as many files, but
it will still work. If you specify this option on a non-GT
15 system, the door will not work correctly. If you do
not specify this option on a true 15 system, BGQWK will
not work.
A Normally, BGQWK gives users the option to read the NEWS file
(GTBULLET.CBS or another file if you specified the NE=
configuration option in the BGQWK.CNF file) whenever its
updated or all the time. If the A option is specified, BGQWK
will override the user's setting and send the NEWS option
during all download of QWK packets.
B If you are running GT 17 and the current user in the door has
a proper time bank entry in the GTUSER.BBS file (TB=), BGQWK
will reward time bank credit for the number of messages
downloaded (if you specify how many credits received for each
message downloaded) and will deduct credit for any tagged
files downloaded. If you wish for this feature to be
disabled, simply specify the B option on the command line.
C Normally, in the C)onfig menu, the users of the door will be
given the option to choose to ALWAYS view the newsfile or to
view it only when updated. By "viewing" it, meaning that the
newsfile is included in the user's QWK packet. When this
option is used, the users will be given the options of to
NEVER view the newsfile or to do so when updated.
D Normally, if a user uploads a message into an area with
improper flags (say the enter a public message in a private
only message area), the message will be moved to the sysop
message base (or general message base if a sysop message base
does not exist). If this option is specified, in essence, it
tells BGQWK to "don't move" the messages, but leave them in
their current base, but change the message flags to an
something which is acceptable for the current conference.
F If specified, BGQWK will make a request to the user's offline
reader that Fido style taglines should be used on all uploaded
messages. Please note that the user's offline reader must
support the "FIDOTAG = YES" command in the DOOR.ID file for
this command line option to work.
G If specified, BGQWK will allow users to select the Ymodem-G
protocol. Remember, you must have a registered copy of DSZ
in order for this to work. If you do not, DSZ may abort
because of invalid parameters. Also, do not use this option
unless you have some type of error correction hardware built
into your modem (such as MNP or LAP-M).
H Normally, the door will allow users to logoff from within the
door. However, many sysops do not want this, because their
systems may be rebooted (if not using DVDOOR) or just because
they want their users to exit from the board. This option,
when specified, will not drop carrier when the users select
the G)oodbye option, but rather, simply return the user to
the board. All that needs to be done to prevent the computer
from rebooting without this parameter is install the small
DVDOOR TSR in your AUTOEXEC.BAT file.
I This option will allow net status users to have any private
mail included in their packet. The private mail will come only
out of the conferences they are granted net status into.
K Normally, any messages sent to your board through BGQWK have
either no security or a private status. This option, when
specified, makes messages with no security change to no kill
status. Use of this option is entirely up to you.
L If you are running GT 17, normally, users may tag files, open
the BGQWK door, and download their QWK packet and tagged
files. All tagging requires that you have a FILES.CTL file
created with the FILES_DB program or clone. BGQWK also has a
nice little feature: your users can remotely 'tag' files with
their QWK reader. To do so, they simply enter a message to
BGQWK with a subject of DL:filename.ext. Of course, BGQWK does
checks for sufficient time, and updates USER.CTL with the number
downloaded files and downloaded kilobytes, but some sysops may
want to disable this local/remote tagging feature. That may be
done with the L option.
M If specified, BGQWK will use DSZ in MobyTurbo mode.
Remember, you must have a registered copy of DSZ in order for
this to work. If you do not, DSZ may abort because of
invalid parameters.
N Normally, the user has the option to have BGQWK do a scan for
new files when they choose to download a QWK packet. For
some reason or another, if you wish to have the file scan
disabled, simply specify this option.
O BGQWK normally creates a BGQWKpid.LOG file. This option
surpresses logging.
P BGQWK normally creates a BGQWKpid.LOG file. This option allows
you to pipe all logging into the GT.LOG file in "comment" format.
Q Normally, if a fatal error occurs, BGQWK will sound three
short bells to alert the user and sysop. If you wish to disable
the bell and use BGQWK in "quiet" mode, use this option.
R Normally, when messages are uploaded, if their messages are
replies to other messages, the reference number may be added
to the header. If you renumber your message bases, any
reference numbers sent through the door will be meaningless.
This option should be used only if you renumber your message
bases or if you just hate reference numbers.
S Normally, BGQWK uses DSZ in "handshake both" mode. If this
option is specified, BGQWK will use DSZ in "handshake slow"
mode. (If you are using HS/Link, this option will also use
HS/Link is slow handshake mode using the -HS parameter).
Only use this option if your users are having trouble sending
or receiving files through the BGQWK door. Some older
systems have trouble with communicating over serial lines and
writing to the hard disk at the same time.
V Normally, if a user enters a netmail message, BGQWK will
attempt to verify the Net/Node in the message against the
NODELIST.BBS file found in the GTPATH directory. If the node
is listed, BGQWK will allow the user to send mail to that
system (provided they have enough netmail credit, etc, etc).
However, if you wish to bypass this search for some reason or
another, simply use the 'V' option to disable the scan.
W Normally, if a message area has a WELCOME.BBS or WELCOME.CBS
file in it, the proper file will be shown to the user if he
joins that message area from the door. This can be supressed
with this parameter.
X This will enable "express duplicate scan". Normally, when a
user uploads a REP packet, all messages will be scanned for
duplicates. On many systems this can take quite a long time,
so, in effect, this option speeds up the scan tremendously,
however, there is a catch: in "express" mode only the first
message is checked for a duplicate and then duplicate
checking is turned off if the first message passes. If the
first message is a duplicate, the duplicate scan will
continue to take place on every message until the first
non-duplicate message is found. This will still take care of
about 90% of the duplicates and will run much faster.
Z Normally, on registered versions of BGQWK, a BGQWK tagline
will NOT be displayed, however, if you wish to show off your
registration, this parameter will force BGQWK to show the
tagline for registered users. Unregistered users always
have the (Unregistered Evaluation Copy) tagline shown.
Please note that when specifing options, no matter how many
options you wish to use, they must be specified in a "squeezed"
format, like so:
┌─── command line options
bgqwk mgskhrlb d:
└─── work drive
You may not want to use any command line options at all. If not,
simply use a "dot" as the options, like so:
bgqwk . c:
That would cause BGQWK to run with all defaults and use drive C:
as the work drive.
-------------------------------------------------------------
THE DOOR ITSELF
-------------------------------------------------------------
The supplemental BGQWK files such as BGQWK.HLP and BGQWK.KEY (for
registered users) are to be placed in the LANPATH directory (the
directory where your USER.CTL file is located). The BGQWK.CNF
file can be placed in your LANPATH or in the GTPATH directory
since many network program alias drive letters.
BGQWK has internal commucations routines so external drivers such
as GATEWAY or DOORWAY are not needed. AGAIN, BGQWK does NOT need
GATEWAY or DOORWAY.
BGQWK also has an internal ANSI driver, so the sysop need not run
ANSI.SYS in order to see color on the bulletin board end. ANSI
music will not be played. The users will not be able to beep you
with the Control-G key.
The COM port being used is taken out of the GT.CNF file under the
CM= directive. The DTE and DCE BPS rates are taken from the
GTUSER.BBS file. The COM port is opened at the DTE rate, and
estimates are based off the DCE rate.
BGQWK constantly checks the COM port for a CARRIER DETECT
indicator. If carrier is lost, BGQWK will return to the board
where GT will log the user off.
If a user selects G)oodbye from within the door, DTR is dropped
until CD is low, then DTR is raised and BGQWK will then return to
the board where GT will log the user off.
If there is no input within four minutes, the door will
automatically return to GT.
BGQWK offers Xmodem, Ymodem, Ymodem Batch and Zmodem at all times
using the DSZ protocol driver. Be sure a DSZ protocol driver is
located somewhere in your DOS PATH. First, GSZ.EXE will be
searched for. If not found, DSZ.EXE will be searched for. If not
found, DSZ.COM is searched for. If not found then, BGQWK will
abort. To enable Ymodem-G, see the "G" command line option.
Paul Meiners' external Zmodem driver, GTZ, is NOT supported
because its Zmodem not 100% compatible with DSZ.
BGQWK will also search for Sam Smith's HSLINK.EXE program in your
DOS PATH. If found, BGQWK will allow your users to optionally use
the HS/Link high speed bi-directional protocol so they can
download QWK packets and upload REP packets at the same time.
When a user is in the door, a simple chat mode can be activated
from the sysop end by the Control-P key. A shell to DOS can be
performed using the Alt-1 key.
The users can create QWK packets in three different flavors. ZIP,
ARJ and LHARC. When BGQWK starts up, it first checks to make sure
you have a copy of PKZIP.EXE and PKUNZIP.EXE in your DOS PATH.
After that, it will check for ARJ.EXE (although this is not a
requirement). Then, it'll check for LHA.EXE or LHARC.EXE (some
people may have renamed newer versions of the program to LHARC).
If you plan on allowing your users access to LZH packets, please
be sure you use the most current version of the LHA software.
When external programs are shelled to from within BGQWK, such as
DSZ.COM, DSZ.EXE, HSLINK.EXE or COMMAND.COM (for the shell to DOS
function), BGQWK will swap itself out into EMS 3.2 or later (if
at least 10 16K pages are free) or will swap itself into a file in
the work directory. This helps greatly when memory hogs such as
ARJ.EXE, LHARC.EXE and PKZIP.EXE are executed by the door. For
your information, the swap file will be called BGQWKpid.SWP.
BGQWK will automatically delete the file upon exit.
BGQWK utilitizes the PID_FILE.BBS file on LAN systems so that
sysops (and users) can have an idea of what the user is doing on
the remote node.
If a user uploads a message with the first three characters of the
subject equal to 'NE:', BGQWK will mark the message as (BAGGED) so
that the MBAGGER program will not process it and send it into the
network. NE stands for "no-echo".
Additionally, this information is provided to the user:
If you wish to send a netmail message in the netmail message area, be
sure to have the destination Net/Node by itself on the first line of
the message. A netmail message does not have to be entered into the
netmail conference. This door will automatically route any netmail
message into the proper conference if you have access to it.
Many offline QWK mail readers internally support the remote adding and
droping of conferences via the standard ADD and DROP commands.
If you wish to enter a message in an echomail conference but have it
so that it does not echo out into the network, the first three
characters of the message subject must be 'NE:'.
It is also possible to remotely tag files. To do so, enter a dummy
message to 'BGQWK' with a subject of 'DL:filename.ext'. For example,
if you wished to remotely tag the file BGQWK10.ZIP, enter a message to
'BGQWK' with the subject line of 'DL:BGQWK10.ZIP'. The text part of
the message is just a dummy field.
-------------------------------------------------------------
MODES OF OPERATION
-------------------------------------------------------------
Normally, BGQWK works as a logon door, but it can also prepack QWK
packets so that users can call, and download the packets from
inside GT rather than having to wait for the door to load and pack
up new messages.
@echo off
rem -- this batch file runs as an event during some time
bgqwk n f: /pd:John Doe c:\gt\specreq
copy c:\gt\specreq\tranquil.qwk c:\gt\uploads\forjohn.zip
Prepack mode is specified by a third parameter, /PD. If you ever
choose to do this, which I recommend only to experienced sysops,
the user name following the /PD: must be used.
The QWK packet made will be placed in whatever directory specified
after the users last name. It is up to the sysop to place (and
rename) the QWK packet in a directory where the user can access it.
In the above sample batch file, I have an event at time xx:yy where
GT exits, runs BGQWK in prepack mode for John Doe and renames his
TRANQUIL.QWK packet to FORJOHN.ZIP into the new uploads directory.
In both local mode operation and prepack mode operation, any
"downloads" are placed into the sysop's download directory.
CARRIER DETECT is not monitored and no data is sent or received
from the COM port.
In local mode, the sysop can experiment with BGQWK. If he or she
chooses to "upload" a REP packet, it must be placed in the sysop's
outgoing uploads directory for BGQWK to find it. Just a reminder
that the sysop's download directory is specified by TP= in the
GT.CNF file and the sysop's upload directory is specified by the
UP= in GT.CNF).
Prepack mode can also been used in "reverse" --- that is, with the
/PU command in place of the /PD. When initiated in this mode,
BGQWK will use the user name after the /PU: and look for a REP
packet to automatically uploaded. I do not recommend using
Prepack mode in reverse unless you have some SPECIFIC reason to do
so. It was suggested that I include it, and I have, but I don't
plan on giving any more details about it. The only thing I'll
add is that you can do /PU:*user name where the "*" will allow any
REP packets that are Prepack reversed uploaded use the netmail
"dot" commands rather than converting them to stars.
When used in "reverse" mode, the pathname specified is where BGQWK
will look for the user's REP file. Remember, you MUST specify the
pathname on both the /PD and /PU modes.
Sysops can also run BGQWK in local mode without having to modify
their GTUSER.BBS file. Local mode is specified by the /LL
parameter which is used like so:
bgqwk pn g: /ll:*b.j. guillot dummy
The first two parameters work like normal. The '*' before the
users first name and last name you wish to simulate means that
BGQWK will grant them sysop access. The "dummy" is just a dummy
variable that will be used for something in the future. It must
be there for local logon mode to work.
Please note that a local logon does not have to be done this way.
The easiest way to do so is logon locally to your own GT Power BBS
and open the BGQWK door.
-------------------------------------------------------------
NET STATUS
-------------------------------------------------------------
If you aren't interested in QWK networking, you can skip over this
section of the documentation.
I bet this is the part a couple of people were waiting for. There
is another universe out there in BBS message networking than that
based off of the MDRIVER concept. Well, yes, there is that
universe based off of Kip Compton's UTI concept, but now, on any
GT Power board, we can now pick up any network that is based off
of the QWK packet standard. The Networks available include
SmartNet, ILink, TexasNet (for Texas residents), and a whole mess
of other networks.
In order to participate in these networks, you must first download
another piece of software--BGNET. Consult the BGNET documentation
for more information about picking up alternate networks and
placing them in your GT message bases.
However, say a system in town wants to pick up some of your
conferences on your board, this is how you would have to set it
up: (Please note that you must first have permission from your
networks head hancho's before you do this).
Granting Net Status to Users
----------------------------
First of all, let's take another look at my BGQWK.CNF file posted
a while ago.
ns=John Doe/gt
ns=Node Houston/tx
ns=Jimmy Dean/rn gt
There were three NS= entries in the configuration file. That is
okay. NS= is the only directive that can be repeated. Let's talk
about what each of those entries mean.
If "John Doe" opens the BGQWK door, he will be granted "net
status" in any conference that has a net id of "GT".
┌─── net id
015 | z | Gfx Proj | rn=D:\MAIL\RNET261
040 | 0 | Netmail | lo=D:\MAIL\NETMAIL,N
041 | z | AnsiArt | gt=D:\MAIL\E10-037,P
039 | z | Bg Qwk | gt=D:\MAIL\E02-758,P
└─── net id
Look at this short section from the configuration file.
"John Doe" would be granted net status in conference 41 and
conference 39.
If "Node Houston" opens the BGQWK door, it will be granted "net
status" in any conference that has a net id of "TX".
If "Jimmy Dean" opens the BGQWK door, he will be granted "net
status" in any conference that has a net id of "RN" _or_ "GT".
What in the world does "granted 'net status'" mean? Well,
remember QWK is a very universal format. We don't want some user
like "Joe Blow" downloading mail from all my conferences and
inserting it into his PC Board without the sysop's permission, do
we? So, if "Joe Blow" tries to do this with his QWK networking
software (such as TNet or QNet), he will get an error message, and
out precious GT Network messages are safe. However, if you are
the GT LNC of your city, you may want to give "Joe Blow" net
status authorities in your GT Network conferences. In essence,
"Joe Blow" will become net/node xxx/yyy in the GT Network with his
PC Board system. At present, sending netmail back and forth along
a QWK network is not supported, but experimental bagging
techniques are being used between 001/040 and 001/070. If the
tests are successful, the batch files will be released.
Having "net status" also means having more significant control as
to what kinds of messages can be downloaded and uploaded in a
conference that a user has net status access to. All public
messages in a conference a user has net status in will be
downloaded and the the user can upload messages addressed from
other people. (Meaning "Node Houston" can upload messages from
"Russell Kroll", for example). A regular user without net status
can only upload mail in their own name.
If you wish to allow the net status user to be able to download
private messages in net status conferences, you will have to grant
them that privledge by using the I, Include private messages,
command line option.
Remember, giving someone net status is a PRIVLEDGE. It should not
be given to just anybody. You have to be responsible.
Another Sysop Granting Net Status to YOU
----------------------------------------
Ok, calm down, I can hear you! You want to know how to pick up
those other networks such as SmartNet, ILink, etc., don't you?
I guess you didn't read that little paragraph a page or so back.
You'll need to download BGNET and consult the documention for
further details.
TNET author Greg Hewgill no longer supports using UTI drivers in
the TNET software, so there is NO NEED to download the latest
version of TNET or the latest version of my BGUTI drivers.
(However, if you're interested in joining the RIME (RelayNet
International Message Exchange), or any other network using the
PC Relay and/or PostLink software, you'll need to pick up my BGUTI
file which describes the softeware in more detail).
-------------------------------------------------------------
SPECIAL PEOPLE aka CONFERENCE ALIASING
-------------------------------------------------------------
If, for some reason, you need to have a special conference for
only one user and have several of them, you can set those up
using the "special people" option.
Format: sp=first last/cnf,path Examples:
sp=B.J. Guillot/045,g:\mail\nm_001040
sp=John Doe/045,g:\mail\nm_001099
sp=General Chang/045,g:\mail\nm_030045
045 | 0 | Netmail | lo=G:\MAIL\NM_001070,n
Users who have access to Conference 45 that are not listed in the
special people section, will get the regular netmail conference
(G:\MAIL\NM_001070). However, the conference pathname will be
aliased to whatever new pathname is specified if the user
online is a "special person" as defined in the BGQWK.CNF file.
This option is provided so that, as a GT hub system, you can allow
non-GT sysops in your area to carry GT conferences by giving the
user net status in your GT conferences. Netmail remains a little
difficult, so you have to trick MBAGGER and MDIST to alias their
netmail into difference conferences. (I'm not going to tell you
how to do that). But, once you get that done, you can just place
all your non-GT nodes Netmail area in just one conference without
having to take up extra conference slots.
You can have more than one of the SAME "special persons" in the
same file, as long as you don't duplicate conference numbers. All
"special person" conferences are giving to that person specified
regardless of access level.
-------------------------------------------------------------
BGQWK.CTL
-------------------------------------------------------------
BGQWK.CTL is a file created and maintained by BGQWK. It contains
all important user information such as the user's conference flags,
etc. This file can be deleted at any time, but doing so will
cause all BGQWK user data to be erased. This file will usually be
created on in the LANPATH directory (the directory where GT keeps
its USER.CTL file). If, for some reason, you would like to
utilitize the information in BGQWK.CTL, here is the file format:
type
bgqwkctlrec = record
eofconst : byte; { constant, asc-26 }
name : string[30]; { name, uppercase }
lastdate : string[10]; { last time in conf }
timeout : byte; { seconds 1..99 out }
protocol : char; { protocol }
ziparj : char; { 0=zip, 1=arj, etc }
timesused : word; { used how many }
maxsize : word; { max size in kb }
maxconf : word; { max msgs / conf }
maxmsgs : word; { max msgs / packet }
qwkdnkb : word; { kb downloaded }
upldmsgs : word; { num msgs uploaded }
lastbps : word; { last bps rate used }
uplddate : longint; { new upload date }
inuse : boolean; { in use on a node }
unattend : boolean; { unattended }
chkuplds : boolean; { check for uploads }
chkbull : boolean; { chk new bulletins }
rdnews : boolean; { always read news }
rdwelbye : boolean; { always read welbye }
zeropck : boolean; { send zeromsg packs }
sendyours : boolean; { send mail from you }
unused : array[1..20] of byte; { filler }
yourflag : array[1..128] of byte; {0not,1you,2y/a,3all }
Each user record occupies 220 bytes. The first record is a dummy
record and has the literal "revision5" in the NAME field. The
128 byte YOURFLAG field is bitmapped into 512 "WORD" fields.
-------------------------------------------------------------
ACKNOWLEDGEMENTS
-------------------------------------------------------------
I would like to thank the following people for their assistance
during the beta test phase.
Mark Adams John Albrecht Perry Alexander
Michael Arnett Ted Arsovsky Oliver Bell
Vincent Benoit Dennis Berry Ovid Bilderback
Jon Bird Richard Blackburn Rich Bogut
Roger Buck Jack Burnett Bob Butcher
Chris Carpenter Craig Clark Bob Clarke
Bill Coady Jack Cole Chris Cook
Keith Coyne Tony Crouch James Davis
Ernest Debakey Cam Deduck Jerry Deguzman
Marcos Della Eddie Dodwell Bill Downing
Brian Dukes Steve Elam Ed Ester
Kevin Farmer John Ferra Simon Ferrie
John Fisher Ken Fortier Mike Foshee
Mike Frisch John Glover Ken Greene
James Gunnells Theresa Hadden Jon Hagee
Ted Harper John Harding Randy Hargis
Jack Hazel Kurt Heilbron Kevin Hemphill
Ray Heuer Greg Hewgill Reginald Hirsch
Brian Hoag John Holzer Jerry Hook
Ed Hopper Steve Huffman Dale Hutchinson
Dennis Ivy Rathulvf Jamesson Steve Johns
Joe Johnston Don Jones Wayne Jones
Burgess Kaneko Mike King Chuck Kinmond
Ken Kirkland Mark Kofahl Jim Kreyling
Russell Kroll Rudi Kusters David Lassiter
Warren Leadbeatter Michael Lee Dennis Leong
Dave Lewis Chien-Hsin Lin Dave Liquorice
David Logan Bruce Lloyd Ed Lucas
Ken Ludwig Dan Mancuso Doug Manne
Lawrence Manuel Jesse Massengill Jeremy Mattern
Michele Mauro Mark May Terry McBride
Andy Mcclung Brian Meadows Paul Meiners
Mike Meyer Greg Miller Jim Montgomery
John Moody Steve Moody Gene Newcomb
Bryan Nylin Mike Olah J.K. Oliver
George Omoregie Ken Opdycke Patrick Perea
Douglas Pippel Mike Powell Sam Prater
Benjamin Randolph Mike Reish Joel Rennie
Tony Reynolds Dave Richer Roy Salisbury
Mike Schmieg Kevin Schorzman Paul Schwarz
Joe Separk Robert Smathers Leonard Smith
Laurence Stanley David Stellmack Bill Stone
Daryl Stout April Strong Ray Sulich
Walter Taucher Bill Thomas Roger Thompson
Steve Tucker Charles Vancleef John Vielmann
Frank Vlamings Ben Waggoner Bill Wahlstrom
Bob Wallace Richard Walker Dave Wall
Richard Waltham Mike Ward Stephen Weihman
Harry Whitehead Scott Wills Brian Wood
Raymond Wood Steven Wright Edward Wyche
I've tried not to forget anyone, but my memory is a little
flakey sometimes.
-------------------------------------------------------------
CONTACTING ME
-------------------------------------------------------------
Are you having problems? Please do NOT netmail me. Discuss your
problems out loud in the BG support conference, GT echomail ID,
E02/758 available directly from 001/070 (Russell Kroll technically
sponsors the confernece, all the bagging, etc) but I am always
there as well. (I pick up E02/758 with BGNET/BGQWK bagging
because I don't run any of Paul's MBAG, MDRIVER or MDIST because
its just TOO POWERFUL for me).
You can also contact me by voice during reasonable hours at the
telephone number at the top of this document.
-------------------------------------------------------------
OTHER INFORMATION
-------------------------------------------------------------
This program was compiled under Borland's Turbo Pascal 6.0.
The BGQWK.EXE file is distributed in uncompressed form. It is
recommended you DIET or PKLITE the file so that you can squeeze
more room out of your hard disk.
╔═════════════════════════════════════════════════════════════════╗
║ E02/758 sponsored by 001/070 is the OFFICIAL SUPPORT CONFERENCE ║
╚═════════════════════════════════════════════════════════════════╝
This program is SHAREWARE. If you use this program for more than
four weeks, it is _highly_ recommended you register the program
at it low cost of only US $25. I have put hundreds of hours of
time into BGQWK. Registrations encourage frequent updates.
If you choose to register after the trial time period, please fill
out the included REGISTER.FRM file and send it along with your
check or money order. After allowing two weeks for processing,
you can call my bulletin board at 713-893-9124 (now operating with
V.32bis, V.32, V.42, V.42bis, MNP 2-5) and open the QWKREG door.
A BGQWK.KEY file will then be generated that will register your copy
of BGQWK. The call takes less than three minutes.
Regards,
B.J. Guillot
